63장. Multi-AZ — 장애 대비의 기본
이 장에서 말하고자 하는 것
DB가 한 대만 있으면
그 DB가 죽음 → 서비스 전체 중단
이걸 해결하는 첫 단계가
Multi-AZ 배포
다.
이 장은 RDS Multi-AZ가 어떻게 동작하고
운영에서 무엇을 보장하는지를 본다.
1. Multi-AZ는 무엇인가
같은 DB를 다른 AZ에 한 대 더 띄워두고 동기 복제 한다.
[AZ-A: Primary (쓰기/읽기)]
↓ 동기 복제
[AZ-B: Standby (대기)]
평소에는 Primary만 트래픽을 받는다.
Primary가 죽으면 Standby가 자동으로 Primary가 된다.
2. 자동 페일오버
Primary 장애 감지
↓
DNS 레코드가 Standby를 가리키도록 자동 전환
↓
애플리케이션은 같은 엔드포인트로 계속 호출
페일오버는 보통 60 ~ 120초 안에 끝난다.
애플리케이션이 자동 재연결을 잘 처리하면 사용자는 잠깐의 끊김만 경험한다
3. 읽기 분산이 아니다
여기서 많이 헷갈리는 부분.
Multi-AZ Standby는 트래픽을 안 받는다
- 읽기 요청도 Standby로 가지 않는다
- 단지 장애 대비용으로만 동기 복제된다
읽기를 늘리고 싶다면 Read Replica 가 필요하다 (64장).
4. 비용
Multi-AZ는 사실상 DB를 두 대 띄우는 것과 같다.
컴퓨트 비용: 약 2배
스토리지 비용: 약 2배
운영 서비스에서는 무조건 켠다는 게 일반적이지만
개발 / 테스트 환경에서는 끄는 경우가 많다.
5. Multi-AZ vs Multi-AZ Cluster
RDS는 두 가지 방식의 Multi-AZ를 제공한다.
| 항목 | Multi-AZ (기본) | Multi-AZ Cluster |
|---|---|---|
| 노드 수 | 2 (Primary + Standby) | 3 (Writer + 2 Reader) |
| Standby로 읽기 | ❌ | ✅ |
| 페일오버 속도 | 60~120초 | 더 빠름 (수십 초) |
| 지원 엔진 | 모든 RDS 엔진 | MySQL · PostgreSQL 일부 |
기본 Multi-AZ 로 시작 → 읽기 부하가 명백히 늘면 Read Replica 또는 Cluster 검토
6. 우리 서비스에서
[ECS "orders"]
↓
[RDS PostgreSQL]
├─ AZ-A Primary (active)
└─ AZ-B Standby (동기 복제)
- 평소: AZ-A 가 모든 트래픽
- AZ-A 장애 시: 60~120초 안에 AZ-B 가 Primary
운영 DB는 무조건 Multi-AZ. 비용보다 가용성이 거의 항상 더 비싸다
7. 직접 확인해보기 — CLI
신규 DB에 Multi-AZ
aws rds create-db-instance \
--db-instance-identifier orders \
--engine postgres \
--multi-az \
...
기존 DB에 Multi-AZ 켜기
aws rds modify-db-instance \
--db-instance-identifier orders \
--multi-az \
--apply-immediately
이 변경은 다운타임 없이 켜진다.
페일오버 강제 (테스트)
aws rds reboot-db-instance \
--db-instance-identifier orders \
--force-failover
운영 환경에서 한 번은 실제로 시켜봐야 한다
페일오버가 정말 잘 동작하는지 / 애플리케이션이 잘 재연결하는지 확인
8. 코드로는 이렇게 생겼다 — Terraform
resource "aws_db_instance" "orders" {
identifier = "orders"
engine = "postgres"
engine_version = "16"
instance_class = "db.t4g.small"
multi_az = true # ← 이 한 줄
backup_retention_period = 7
db_subnet_group_name = aws_db_subnet_group.main.name
vpc_security_group_ids = [aws_security_group.db.id]
publicly_accessible = false
deletion_protection = true
}
multi_az = true 한 줄이 두 AZ에 동기 복제를 켠다.
DB Subnet Group이 두 AZ의 서브넷을 갖고 있어야 한다.
9. 애플리케이션 측 고려사항
페일오버가 일어나면 기존 연결은 끊어진다.
- 커넥션 풀이 자동 재연결을 지원해야 한다
- 쓰기 직후 트랜잭션은 실패할 수 있다 → 재시도 로직 필요
- 읽기 전용 모드를 일부 구간에 두는 게 도움이 될 수 있다
운영 DB에 대한 클라이언트는 항상 “끊어질 수 있다” 를 전제로 설계
10. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. 운영 DB에 Multi-AZ 안 켠다
한 AZ 장애로 서비스 전체가 멈춘다.
안티패턴 2. Standby로 읽기를 보낸다고 착각한다
Standby는 트래픽을 안 받는다. 읽기 분산은 Read Replica.
안티패턴 3. 페일오버를 한 번도 시험해보지 않는다
실제 장애 시 애플리케이션이 재연결을 못 해 더 큰 사고가 난다.
정기적으로 force-failover를 시뮬레이션한다
안티패턴 4. DB Subnet Group이 한 AZ만 가진다
Multi-AZ를 켜고 싶어도 안 켜진다.
11. 한 줄로 정리
Multi-AZ는 같은 DB를 다른 AZ에 동기 복제해 두는 장애 대비 구성이며,
운영 DB의 사실상 필수 옵션이다
12. 이 장의 핵심 정리
- Multi-AZ는 같은 DB를 다른 AZ에 동기 복제한 형태다.
- Primary 장애 시 60~120초 안에 자동 페일오버한다.
- Standby는 트래픽을 안 받는다 — 읽기 분산 아님.
- 비용은 약 2배지만 가용성이 거의 항상 더 비싸다.
- 페일오버는 운영에 들어가기 전 반드시 한 번 시험해본다.